Subject: Item 8265

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Mon, 24 Jul 95 09:58:24 EDT

>> The only difficult aspect of implementing this solution is supporting the
>> 6611 APPN MIB (which doesn't use node type as an index into the topology
>> table, so needs some code to handle the rare case when there are two
>> records with the same name but different types).
>>
>> TRH:  TRS doesn't use node type as an index into the TDB either.  It uses
>> TRH:  the node name, hence the problem when duplicates exist.
>
>This is just an internal implementation issue - nothing to do with the
>architecture.  There is nothing in the TRS chapter that specifies how the
>TDB is indexed.

I want to make sure that everyone understands the network management
implications of Mike's proposal:

1.  We would need to split the appnNnTopologyTable and
    appnNnTopologyFRTable into two tables each, one for NNs and one for
    VRNs.

2.  The change would hit not only the SNMP agents in the APPN NN
    products, but also the manager-side SNMP applications that run, for
    example, on NetView for AIX.

3.  This is a significant change for both manager-side applications and
    SNMP agents, since it changes the basic structure of tables that are
    actually being used today.

4.  MIB tables and their indices are not "just an internal implementation
    issue."  Once we have agreed to a standardized APPN MIB, these will
    be just as much a part of the APPN architecture as the TRS chapter.

If the two proposals on the table really are roughly equal in impact from
the standpoint of network node migration, I'll argue that we should let
their impact on network management applications (= none for Tim's
proposal, versus significant for Mike's) serve as the tie-breaker.

Bob Moore